Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-207.txt

Text File | 1994-12-08 | 49.8 KB | 1,278 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 03 Nov 92       Volume 1 : Issue 207

Today's Topics:

    Using ReadXPRam and WriteXPRam traps
    putting the mouse in a cage?
    Q: How to tell the depth of screen?
    If I have the old, do I need to buy the new Inside Mac?
    Gestalt Return Value for 24-bit addressing?
    Writing dcmds in MPW
    HOpen confusion
    Quickdraw region implementation
    Questions relating to direct-to-screen drawing



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Julian Turnbull)
Subject: Using ReadXPRam and WriteXPRam traps
Date: 30 Sep 92 08:56:51 GMT
Organization: Department of Computer Science, Edinburgh University

[ Sorry if you're seeing this twice - I posted a couple of weeks ago, with
  a restricted distribution, but got no response, so I'm casting the net a
  bit wider this time.  JST ]

I'm trying to find some documentation for the _ReadXPRam and _WriteXPRam
traps, which read and write the extended PRAM found in later Macs.
Specifically, I want to be able to get at the latitude, longitude, and
timezone information set by the Map cdev.

"Inside Mac" is remarkably coy about these calls - I got to Volume VI before
I even found an admission that they exist.  However, some people manage to
use them, so the information must exist _somewhere_.  Can anyone enlighten
me?

Thanks in advance,
Julian.


- --
| Julian Turnbull,                               | Phone: [phone]
| Department of Computer Science                 | JANET: [e-mail]
| University of Edinburgh, Edinburgh EH9 3JZ,    | Everywhere else:
| Scotland, U.K.                                 |        [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Robert John Churchill)
Organization: University of Michigan
Date: Thu, 1 Oct 1992 00:17:22 GMT

In article <[e-mail]>, [e-mail] (Julian Turnbull)
wrote:
>
> I'm trying to find some documentation for the _ReadXPRam and _WriteXPRam
> traps, which read and write the extended PRAM found in later Macs.
> Specifically, I want to be able to get at the latitude, longitude, and
> timezone information set by the Map cdev.
>
> "Inside Mac" is remarkably coy about these calls - I got to Volume VI before
> I even found an admission that they exist.  However, some people manage to
> use them, so the information must exist _somewhere_.  Can anyone enlighten
> me?

Use ReadLocation and WriteLocation instead of messing with PRAM.  See
Inside Mac volume 6 Chapter 14..

+++++++++++++++++++++++++++

From: [e-mail] (Martin Minow)
Date: 1 Oct 92 22:31:09 GMT
Organization: Apple Computer Inc., Cupertino, CA


[e-mail] (Julian Turnbull) asks about the ReadXParam and WriteXParam
traps as he needs to access the location (latitude, longitude, and timezone
offset).

The proper way to access this information is by using the ReadLocation and
WriteLocation functions described in the ScriptManager chapter of Inside Mac VI.

Hope this helps.

Martin Minow
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 2 Oct 92 02:13:18 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Martin Minow) writes:
>[e-mail] (Julian Turnbull) asks about the ReadXParam and WriteXParam
>traps as he needs to access the location (latitude, longitude, and timezone
>offset).
>The proper way to access this information is by using the ReadLocation and
>WriteLocation functions described in the ScriptManager chapter of Inside Mac VI

There is a sample program for getting the map information in the
snippets collection, available via anonymous ftp from ftp.apple.com
as

  /dts/mac/sc/snippets/toolbox.iac/other/readlocation.hqx

Setting of this and other information stored in Parameter
RAM is unsupported, underdocumented, and discouraged.

Grobbins        [e-mail]

Usual disclaimers apply.


---------------------------

From: [e-mail] (Graham Heyes)
Subject: putting the mouse in a cage?
Organization: Continuous Electron Beam Accelerator Facility
Date: Wed, 30 Sep 1992 14:35:07 GMT

Two quick questions related to the mouse/pointer...

Firstly how if at all possible can the movement of the
mouse be restricted to one area of the screen, for example
restricting mouse movement to within a particular window ?

Secondly, and probably related, what confines the pointer
to the screen?

     I haven't seen this in any volumes of IM or anywhere
else for that matter so I'm curious as to if it is possible.

            Graham Heyes

+++++++++++++++++++++++++++

From: [e-mail] (_creative_output_)
Organization: Camp Vanderbilt Vision Research Center
Date: Thu, 1 Oct 1992 18:45:38 GMT

Figured this out digging through some MacsBug shorthand equates:

static    Rect    box = {100,100,400,400}, dispR = {20,20,60,160};
        char      outs[20], pouts[20];
        WindowPtr wind;
        int      X,Y,    dl=23, dt=44;

#define    RawMouse    0x082C
#define    Yaddr        (int*) (RawMouse)
#define    Xaddr        (int*) (RawMouse+sizeof(int))

#define    MTemp        0x0828
#define    YaddrT        (int*) (MTemp)
#define    XaddrT        (int*) (MTemp+sizeof(int))

main()
{
InitMacintosh();
wind = NewCWindow( 0L, &screenBits.bounds, "\p", true, plainDBox,-1L,true,0 );
SetPort( wind );    ShowWindow( wind );       EraseRect(&screenBits.bounds );
FrameRect( &box );
while ( ! Button() )
    {
    X = * Xaddr;    Y = * Yaddr;            /* get raw mouse pos  */

    if ( X > 400 )    * Xaddr = * XaddrT = 100;   /* force x if too big */
    if ( X < 100 )    * Xaddr = * XaddrT = 400;   /* force x if too lil */
    if ( Y > 400 )    * Yaddr = * YaddrT = 100;   /* force y if too big */
    if ( Y < 100 )    * Yaddr = * YaddrT = 400;   /* force y if too lil */

    sprintf( outs, "%d,%d", X,Y );    CopyCToPas( outs, pouts ); /*  tell  */
    EraseRect( &dispR );  MoveTo( dl,dt );  DrawString( pouts ); /*   us   */
    }
}

... InitMacintosh() does the usual mac init stuff ...

That should do it!  (I guess i originally intended to use the Rect 'box'....)


- - Dave Bloom

"He who speaks the truth           - Arabian saying,
 better have one foot in the stirrup"    from _Moon_Over_Morocco_,
                                         by Meatball Fulton & ZBS Foundation

+++++++++++++++++++++++++++

From: [e-mail] (Scott Kevill)
Date: 2 Oct 92 01:49:56 GMT
Organization: Curtin University of Technology

There used to be a lovely global variable called PinMouse (can't
remember the location offhand) that contained a rectangle that did
all this work for you. The other advantage was that it worked with
everything and wasn't just while a loop was executing.

This global variable worked fine until System 7 came along - it
has no effect and System 7 seems to continously reset this variable.
However this should work fine on any system before 7 although it
may not be of much use.

Hope this helps !

Scott

+-----------------------+--------------------------------------+
I Scott Kevill          I   "Be like me, be original"          I
I [e-mail] I                              -- Me   I
+-----------------------+--------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 2 Oct 1992 03:38:51 GMT

[e-mail] (Scott Kevill) writes:
>There used to be a lovely global variable called PinMouse (can't
>remember the location offhand)

0x0834.

>that contained a rectangle that did
>all this work for you. The other advantage was that it worked with
>everything and wasn't just while a loop was executing.
>
>This global variable worked fine until System 7 came along - it
>has no effect and System 7 seems to continously reset this variable.
>However this should work fine on any system before 7...

If I recall correctly, it failed to have any effect on any of the
machines with Color QuickDraw I tried.  It worked on my SE and failed
on a IIcx running 6.0.x.  But I didn't test it on many machines...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I'm your only friend, I'm not your only friend, but I'm a little glowing
 friend, but really I'm not actually your friend, but I am...

---------------------------

From: [e-mail] (Ted Lowery)
Subject: Q: How to tell the depth of screen?
Organization: MacSolutions
Date: Wed, 30 Sep 1992 18:12:19 GMT

Hi all-

Question:  What is the best way to tell the depth of the default screen when
your application starts up?  The way I am currently doing is to check
SysEnvirons.hasColorQD, and if so, I create a color port with the following:

if (myEnv.hasColorQD) {
        myCGrafPtr = NewPtrClear(sizeof(CGrafPort));
        OpenCPort(myCGrafPtr);
        theDepth = (**(*myCGrafPtr).portPixMap).pixelSize;
        CloseCPort(myCGrafPtr);
        }
else theDepth = 1;

seems to me, there is probably a lot of overhead involved here, and there
should to be a simpler way.  I need to do it before I open a window, so that
I know which type of window, and what size to open.

Also, what is the screen size of the 12" bw and color monitors like the
LC use?

Thanks...

+----------------------------+----------------------------+
|  Ted Lowery                |              MacSolutions  |
|  [e-mail]      |              PO Box 30051  |
|  CIS: 76350,2613           |        Raleigh, NC  27622  |
+----------------------------+----------------------------+
|  A bore is someone who persists in holding his own      |
|  views aster we have enlightened him with ours.         |
+---------------------------------------------------------+


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 30 Sep 1992 18:56:10 GMT

[e-mail] (Ted Lowery) writes:
>
>What is the best way to tell the depth of the default screen when
>your application starts up?  The way I am currently doing is to check
>SysEnvirons.hasColorQD, and if so, I create a color port...
>seems to me, there is probably a lot of overhead involved here, and there
>should to be a simpler way.

Yep.  Try (**(**GetMainDevice()).gdPMap).pixelSize.

>Also, what is the screen size of the 12" bw and color monitors like the
>LC use?

Both mono and color 12" are 512x384.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: Andrew Gilmartin <[e-mail]>
Date: 30 Sep 1992 23:20:31 GMT
Organization: Brown University

In article <[e-mail]> Jamie R.
McCarthy, [e-mail] writes:

>Yep.  Try (**(**GetMainDevice()).gdPMap).pixelSize.

I had a similar need, but I wanted to find out if any attached
device was using black and white only. Since there is no
complement to GetMaxDevice(), here is a kind is GetMinDevice().

Boolean IsMonochrome( void )
{
     GDHandle theDevice;

     for ( theDevice = GetDeviceList()
          ; theDevice
          ; theDevice = GetNextDevice( theDevice ) )
          if ( (**(**theDevice).gdPMap).pixelSize == 1 )  // Is
device using monochrome?
               return TRUE;

     return FALSE; // Using color on all devices

} /* IsMonochrome */

Note: Just checking the device type is no enough, you have to
check the pix map.

- -- Andrew

+++++++++++++++++++++++++++

From: Andreas Wuertz <[e-mail]>
Organization: Federal Institute of Technology
Date: Thu, 1 Oct 1992 08:19:46 GMT

In article <[e-mail]> Jamie R. McCarthy,
[e-mail] writes:
>Both mono and color 12" are 512x384.

Is there a special bw monitor for the LC? Because the standard bw 12"
monitor has 640x480 pixels. 512x384 is right for the 12" colour monitor.
By the way: Start ResEdit 2.1 and create/open a ALRT, DLOG or WIND
resource. You'll get a menu called 'MiniScreen' which has all the current
sizes in it.

Andy ([e-mail])

========================================================================
The only person who got all his work done by Friday was Robinson Crusoe.
========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (J. S. Greenfield)
Date: 1 Oct 92 14:38:53 GMT
Organization: Syracuse University, CIS Dept.

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>>Also, what is the screen size of the 12" bw and color monitors like the
>>LC use?
>
>Both mono and color 12" are 512x384.

The color is 512x384 (about 55 dpi, I think), but the mono is 640x480 (72 dpi).


- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

---------------------------

From: [e-mail] (John Mignault)
Subject: If I have the old, do I need to buy the new Inside Mac?
Date: Wed, 30 Sep 1992 22:15:26 GMT
Organization: PANIX Public Access Unix, NYC

The subject line just about says it all. The bookstore where I work just
got three volumes of the new Inside Mac, and I was wondering, before I
decide to spend another $200 or so on the six new books, just how much I'll
actually need them if I already own the original six. I understand they're
probably pretty cool and slick and suchlike, but if I can afford not to buy
them ( at least right now ), I won't. Any opinions?

John Mignault
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 1 Oct 1992 03:38:46 GMT

[e-mail] (John Mignault) writes:
>The subject line just about says it all. The bookstore where I work just
>got three volumes of the new Inside Mac, and I was wondering, before I
>decide to spend another $200 or so on the six new books, just how much I'll
>actually need them if I already own the original six.

Do you have a CD-ROM drive?

September's developer CD arrived a few days ago, and I was pleasantly
surprised to find all three currently-existing New Inside Macintosh
volumes on it.  (Although I was puzzled to not see an issue of
_develop_.  Anyone know what's up?)  Sure, browsing's slow off the CD,
and they'll take up ten megs if you copy them to hard disk--but you can
always print them yourself, and besides you can't electronically search
the paper version.

Do I remember right that a year's subscription to the developer CD runs
something like $30?  (If you can confirm or correct this, please email
me.)  If so, and if you have a CD-ROM drive--snap it up.  If you don't
have a CD-ROM...hey, it's about the same price as the next umpteen
New Inside Macintosh books.  :-)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 1 Oct 92 08:47:58 GMT
Organization: Personal

In article <[e-mail]>, [e-mail] (John
Mignault) wrote:
>
> [...] I was wondering, before I decide to spend another $200 or so on the
> six new books, just how much I'll actually need them if I already own the
> original six.

well, actually its going to be more like 15 new volumes, and the TN are
going to be withdrawn as they are obsoleted by the new volumes, so you
probably should get them, after all, apple's new publishing venture might
go broke if we decided to boycott it.
- --

Dana S Emery <[e-mail]> | "Novo, de Novo,
                                  |     de novo, de no-o-o-o-o---,
                                  | Novemba come an' dey gonna go home."

+++++++++++++++++++++++++++

From: [e-mail] (Tim Hammett)
Date: 1 Oct 92 20:37:25 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Jamie R. McCarthy) writes:
>Do I remember right that a year's subscription to the developer CD runs
>something like $30?  (If you can confirm or correct this, please email
>me.)  If so, and if you have a CD-ROM drive--snap it up.  If you don't

This isn't totally correct - a year's subscription to develop (which includes
four of that year's developer disks) costs $30 to US subscribers.

The full developer mailing (12 CD's per year, plus the occasional other
goodie, but excluding any betas) is available from APDA, & costs around
$250 + shipping (which is substantial).

(^^ I don't have my APDA catalog handy, so I'm not totally sure of the $250
figure, but it's that order of magnitude).

- --
Tim Hammett, Botany Dept, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Peter Bierman)
Organization: Blue Moon BBS ((614) 868-998[024])
Date: Thu, 01 Oct 92 14:56:56 EDT

[e-mail] (Jamie R. McCarthy) writes:

> Do I remember right that a year's subscription to the developer CD runs
> something like $30?  (If you can confirm or correct this, please email
> me.)  If so, and if you have a CD-ROM drive--snap it up.  If you don't
> have a CD-ROM...hey, it's about the same price as the next umpteen
> New Inside Macintosh books.  :-)

Yep. It's $30 plus tax. $25 if you get one of those purple cards from
someone who already gets it. That's only 4 CDs though. One every three
months.


- ---
The opinions I express are rarely my own, because my own are far too
outragous to post here.

IntNet:SEE NOTE BELOW            FutureNet: #33@#10
The Metropolis (614)-846-1911
- ---
Internet Address: Send two copies of everything to:
[e-mail] and [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Peter Bierman)
Date: 1 Oct 92 18:54:10 GMT
Organization: Blue Moon BBS ((614) 868-998[024])

[e-mail] (John Mignault) writes:

> The subject line just about says it all. The bookstore where I work just
> got three volumes of the new Inside Mac, and I was wondering, before I
> decide to spend another $200 or so on the six new books, just how much I'll
> actually need them if I already own the original six. I understand they're
> probably pretty cool and slick and suchlike, but if I can afford not to buy
> them ( at least right now ), I won't. Any opinions?

Well, I own all 6, + IMCTB, + XREF, + Hardcopy of all TNs. I just bought
the first 3 new ones, and I must say that I'm QUITE impressed. The fact
that everything in them is ACCURATE, and COMPLETE just about pays for
itself. AL least get "files" because the old way to do files involves
memorizing IM2, 4, and 6, + about 12 tech notes.

In short, the new ones are worth it. They're jammed with source code, and
the biggest part of each chapter is the ENGLISH explanation about how it
all works together.


- ---
The opinions I express are rarely my own, because my own are far too
outragous to post here.

IntNet:SEE NOTE BELOW            FutureNet: #33@#10
The Metropolis (614)-846-1911
- ---
Internet Address: Send two copies of everything to:
[e-mail] and [e-mail]

---------------------------

From: [e-mail] (Andrew E Page)
Subject: Gestalt Return Value for 24-bit addressing?
Date: 2 Oct 92 13:22:52 GMT
Organization: The World Public Access UNIX, Brookline, MA


    What does the Gestalt Trap return when 24-bit addressing is
in effect?  It returns a 0,1, or 2 when various flavors of 32-bit
is in effect, at least according to GestaltEqu.a.  Or does it
simply pass back a non-zero result code in D0?

- --
Andrew E. Page   (Warrior Poet) |   Decision and Effort The Archer and Arrow
Mac Consultant                  |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 2 Oct 92 18:49:16 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (Andrew E Page)
wrote:
>
>
>     What does the Gestalt Trap return when 24-bit addressing is
> in effect?  It returns a 0,1, or 2 when various flavors of 32-bit
> is in effect, at least according to GestaltEqu.a.  Or does it
> simply pass back a non-zero result code in D0?
>
> --
> Andrew E. Page   (Warrior Poet) |   Decision and Effort The Archer and Arrow
> Mac Consultant                  |     The difference between what we are
> Macintosh and DSP Technology    |           and what we want to be.

The 0,1 and 2 are bit numbers, as is the standard for gestalt...Attr
selectors, as described on page 3-34 of Inside Mac VI.  Thus, if
you were in 32-bit mode, the response would generally be $00000007, or
binary 00000000000000000000000000000111, having bits 0,1, and 2 set;
the same Mac in 24-bit mode might return $00000004 (binary ...0100),
having only the 32-bit capable bit set.

Tim Dierks
MacDTS

+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Date: 2 Oct 92 20:52:56 GMT
Organization: Verity, Mountain View, CA, USA

In article <[e-mail]> Andrew E Page,
[e-mail] writes:
>    What does the Gestalt Trap return when 24-bit addressing is
>in effect?  It returns a 0,1, or 2 when various flavors of 32-bit
>is in effect, at least according to GestaltEqu.a.  Or does it
>simply pass back a non-zero result code in D0?

Bit 0: 32-bit addressing mode
Bit 1: 32-bit clean System Heap
Bit 2: Machine is 32-bit capable

In your case, I would probably test if bit 0 is off.

---------------------------

From: [e-mail] (Christopher Evans)
Subject: Writing dcmds in MPW
Date: 1 Oct 92 20:43:31 GMT
Organization: Natural Intelligence, Inc.

I am trying to write a dcmd in MPW or Think C and I am having a heck
of a time!  The dcmd uses some ANSI calls and a couple of toolbox calls.
The problem is that I can't link it in MPW.  The sample dcmd on the
developer cd's links a file called "{CLibraries}CInterface.o which I don't
have.  Where is this file?

Can I also be safe in assuming that I should not waste my time trying to
write a dcmd in Think C?

<=================================Q=================================>
 Chris Evans                      |   Internet: [e-mail]
 Senior Macintosh Programmer      |   Phone: [phone]
 Natural Intelligence, Inc.       |   FAX:   [phone]
 2067 Massachusetts Avenue        |   AppleLink: NATURAL
 Cambridge MA  02140              |   or [e-mail]@internet#

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 2 Oct 92 19:22:12 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail]
(Christopher Evans) wrote:
>
> I am trying to write a dcmd in MPW or Think C and I am having a heck
> of a time!  The dcmd uses some ANSI calls and a couple of toolbox calls.
> The problem is that I can't link it in MPW.  The sample dcmd on the
> developer cd's links a file called "{CLibraries}CInterface.o which I don't
> have.  Where is this file?
>
> Can I also be safe in assuming that I should not waste my time trying to
> write a dcmd in Think C?

OK; I'd suggest you write the dmcd in MPW, because the tools are designed
to work in MPW; I don't have any idea how you'd do it in Think C.  You're
going to run into two problems, because the dcmd stuff was designed for
MPW 3.1, and there's been two significant changes:
  1) CInterfaces.o and CRuntime.o were eliminated
  2) The segmentation strategy for a lot of routines changed

You're currently running into 1); it's trying to link with CInterface.o,
and it doesn't exist.  Replace all references to "{CLibraries}"CRuntime.o
with "{Libraries}"Runtime.o and replace "{CLibraries}"CInterface.o with
"{Libraries}"Interface.o.  Note you will usually have two references
to "{Libraries}"Interface.o now; you can delete one of them.

You'll soon run into 2).  The BuildDCMD tool expects a very specific
segmentation, and because the libraries were resegmented in MPW 3.2,
it can't recognize things, so you'll need to merge the extraneous
segments into the "Main" segment.  You'll need to add arguments like
- -sg Main=StdIO,StdLib to your link line.  The easiest way to determine
which segments you've got that need to be merged is to link the dcmd
without merging anything, then open it with RedEdit and look at the
CODE resources; they'll all have names, and each resource's name
is a segment name.  You need to merge all the segments except for
%A5Init into Main.  So write down all the names of all the other
segments and add this argument to your link line:
  -sg Main=segName1,segName2,and,so,on
This will merge all the named segments into Main, giving you the
canonical 2-segment file BuildDCMD wants to use.

Enjoy;
Tim Dierks
MacDTS

---------------------------

From: [e-mail] (Michael Hecht)
Subject: HOpen confusion
Date: 21 Sep 92 14:40:56 GMT
Organization: SAS Institute Inc.

This is probably obvious to everyone, but...

I'm trying to call PBHOpenDFAsync, which takes an HParmBlkPtr, and I'm
getting confused.

* Which variant of the HParamBlockRec do I use? The field names in IM
imply that I should use IOParam, except it doesn't contain an ioDirID.
Ok, I'll use FileParam instead, except it doesn't contain an ioPermssn or
ioMisc. [Confusion?!?!?]

* Nowhere in IM-Files is it stated what variant goes with what routine.
It only offers this extremely useless admonition: "When you call a
low-level routine, you pass the address of the appropriate parameter
block to the routine." How profound! I thought I should pass an
inappropriate parameter block. Thanks for the sage advice!!
[Frustration!!!!!]

* Is ioMisc still used for Opens? IM-IV says I should set it to NIL or to
an I/O buffer. IM-Files doesn't say anything about it with regards to the
HOpen family. [Omission?????]

* IM-Files makes no mention of zeroing the version number in the Open
descriptions. It does, however, mention it in the Data Structures section
that describes the HParamBlockRec. Do I still need to set it to zero for
HOpen? If I'm using the FileParam variant, do I set both ioFVersNum and
ioFlVersNum? Probably not, since the second one overlays ioMisc, which
maybe should or shouldn't be set to NIL. Wouldn't I be totally in the
dark if I were new to this game? [Disappointment...]

Anxiously awaiting the blinding light of truth...
- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 21 Sep 92 16:50:30 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> Michael Hecht <[e-mail]> writes:
>I'm trying to call PBHOpenDFAsync, which takes an HParmBlkPtr, and I'm
>getting confused.
>
        You probably want to make that a Sync open, don't you?

>* Which variant of the HParamBlockRec do I use? The field names in IM
>imply that I should use IOParam, except it doesn't contain an ioDirID.
>Ok, I'll use FileParam instead, except it doesn't contain an ioPermssn or
>ioMisc. [Confusion?!?!?]
>
        I use an HParamBlockRec and then set it up as follows:
pb.fileParam.ioCompletion = NULL;
pb.fileParam.ioVRefNum = vRefnum;
pb.fileParam.ioDirID = dirID;
pb.fileParam.ioNamePtr = (StringPtr) fName;
pb.ioParam.ioPermssn = fsRdWrPerm;
pb.ioParam.ioMisc = (Ptr)NULL;
        and then call PBHOpenDFsync, remember that this will NOT work under
System 6.

>* Is ioMisc still used for Opens? IM-IV says I should set it to NIL or to
>an I/O buffer. IM-Files doesn't say anything about it with regards to the
>HOpen family. [Omission?????]
>
        I don't know if it is still used or not, but it doesn't hurt to set it.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Steven Dorner)
Date: 27 Sep 92 15:46:28 GMT
Organization: Qualcomm, Inc

In article <[e-mail]>, Michael Hecht
<[e-mail]> wrote:
> * Is ioMisc still used for Opens? IM-IV says I should set it to NIL or to
> an I/O buffer. IM-Files doesn't say anything about it with regards to the
> HOpen family. [Omission?????]

Set it to NIL.  I had a very disturbing experience with ioMisc.  My program
would crash at more or less random times.  No matter where I set
breakpoints, it would crash somewhere else; but only on MacPlusses and
SE's; II's and up were fine.  All these machines were running whatever was
current at the time (6.0.5, I think).

The culprit was ioMisc.  I was failing to zero it, and this made SE's and
Plusses go bonkers (at unpredictable times, since the buffer's only used
when a track needs to be transferred), whereas it didn't affect II's at
all.

I concluded from this that ROM's since the II's must ignore ioMisc on
opens.  However, I wouldn't bet my life on it, and you don't want to cut
off SE's and Plusses (SE's especially, since they're better machines than
Classics).

---------------------------

From: [e-mail] (Douglas Scott Bassett)
Subject: Quickdraw region implementation
Date: 28 Sep 92 22:19:16 GMT
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.

Does anyone know exactly how Quickdraw regions are implemented on the MAC?

+++++++++++++++++++++++++++

From: [e-mail] (Chris Wysocki)
Date: Tue, 29 Sep 92 01:56:37 GMT
Organization: Connectix Corporation, San Mateo, CA

In article <[e-mail]> [e-mail] (Douglas
Scott Bassett) writes:

>Does anyone know exactly how Quickdraw regions are implemented on the MAC?

A QuickDraw region consists of a series of "inversion points", i.e.
points at which one goes from outside the region to inside or vice
versa.  These points are stored in ascending scanline order following
the rgnSize and rgnBBox fields in the region handle.  Each scanline in
the region data starts with the vertical coordinate, followed by the
horizontal coordinates of the inversion points on that scanline.
(Since regions are closed, there are always an even number of
horizontal coordinates per scanline.)  The last horizontal coordinate
on a scanline is followed by $7FFF, which marks the end of the
scanline data.  This is repeated for each scanline in the region; a
vertical coordinate of $7FFF marks the end of the region data.
Rectangular regions are the one exception to this format; such regions
contain no inversion point data (i.e. "GetHandleSize(theRegion) ==
sizeof(Region)") and are fully described by their bounding rectangle
(the rgnBBox field).



- --
Chris Wysocki
[e-mail]
[e-mail]


---------------------------

From: [e-mail] (Doug McNaught)
Subject: Questions relating to direct-to-screen drawing
Date: 29 Sep 92 04:50:37 GMT
Organization: California Institute of Technology


Hey friendly netters,
  A friend of mine is working on a program that draws directly to the
screen in a window, and he has some questions about StripAddress and
maintaining as much compatibility as possible with various models. The
program runs in 8-bit mode and requires Color QuickDraw. I'm going to
append the message he sent me and you can reply to him, myself, or the
net--I'll make sure he gets any useful responses.

His name is Alexei Lebedev and he can be reached at
  [e-mail]

- ------here we go!!!------

Doug,-

I'd be very grateful if you posted my problem on UseNet. In particular, I need
to know the following:

1). IM says "strip when the system may be running 24 bit mem manager". I guess
any system can run 24 bit memory manager. Also, no my global MaskBC variable
is always 0x00FFFFFF, even when I'm in 32 bit mode. That means I'm always
running 24 bit mem manager.

2). How do you tell the hardware to operate in 32 bits? Should I use stripped
addresses right away, or can I keep a variable that's a stripped address? In
particular, when I lock my Image data structure, I do the following:

HLock(destImage->baseH);
CheckOS(MemError(), "LOCK");    /* last parameter is a routine name */
destImage->baseAddr = StripAddress(*destImage->baseH);

Is this the right way to do this?

3). When I start writing to the screen, I switch to 32 bit addressing with
SwapMMUMode. Does this have any effect on a computer like LC?

4). I use screenbits.baseAddr to get screen memory's base address. Is this
address 32 bit clean no matter what? (I guess it should be, since it doesn't
point to a memory manager block.) Is this a base address of the main screen?

5). When I switch pixel depth, screenBits.rowBytes remains the same. This is
very nasty. What is the right way of getting screen's base address, and should
I always switch machine to 32 bit addressing mode before writing to the
screen?

6). How come screenBits is a bit map, but the screen is color? since
screenbits is a bitmap, the high bit of its rowBytes should be cleared. This
means using copyBits on the screen will produce b/w images, if not nonsense.

7). At what times EXACTLY should strip address be used, and at what times
EXACTLY should SwapMMUMode be used?

These are just some of the questions that bug me. Also, if I want to write to
another screen, do I call SetGDevice? If so, what happens to my screenBits?
Can the device be changed when I call WaitNextEvent? I mean, when I return
from WaitNextEvent, should I always switch to the my own device, like I do
with ports?

I used to calculate screen width by taking screenBits.rowBytes and multiplying
it by 8. However, when I start up in 4 bits and then switch to 8 bits (by
using SetDepth), the cube becomes twice as large, instead of being twice as
small. This doesn't make much sense to me. Also it doesn't make sense that in
1 bit mode screenbits.rowBytes is 1024 (!!), while in 8 bit mode it's 512
(??).

Hope some of them get answered.
Have fun.
- -Alexei

- --
Doug McNaught              |"Sadder still to watch it die/ Then never to have
[e-mail]      | known it/ For you, the blind who once could see/
[e-mail]     | The bell tolls for thee..." --Neil Peart
  Nobody approves my opinions! Not even me, sometimes. Read at your own risk.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 29 Sep 92 12:04:52 GMT
Organization: Kalamazoo College

[e-mail] (Doug McNaught) writes:
>
>  A friend of mine is working on a program that draws directly to the
>screen in a window, and he has some questions about StripAddress...
>
>His name is Alexei Lebedev and he can be reached at
>  [e-mail]
>
>1). ... my global MaskBC variable
>is always 0x00FFFFFF, even when I'm in 32 bit mode. That means I'm always
>running 24 bit mem manager.

The global will not tell you;  disassemble _StripAddress in both 24- and
32-bit mode to see why.  (In 24-bit mode, it ANDs the global like you'd
expect;  in 32-bit mode, it returns and does nothing.)

>2). How do you tell the hardware to operate in 32 bits? Should I use stripped
>addresses right away, or can I keep a variable that's a stripped address? In
>particular, when I lock my Image data structure, I do the following:
>
>HLock(destImage->baseH);
>destImage->baseAddr = StripAddress(*destImage->baseH);
>
>Is this the right way to do this?

Looks fine to me.

>3). When I start writing to the screen, I switch to 32 bit addressing with
>SwapMMUMode. Does this have any effect on a computer like LC?

It has an effect on any computer running in 24-bit mode that is capable
of switching into 32-bit mode.  The LC, like most Macs, could fit these
conditions.

>4). I use screenbits.baseAddr to get screen memory's base address. Is this
>address 32 bit clean no matter what? (I guess it should be, since it doesn't
>point to a memory manager block.) Is this a base address of the main screen?

Is it 32-bit clean?  Probably, but why take a chance?  StripAddress is a
very quick call.  Is it the baseAddr of the main screen?  Yes.

>5). When I switch pixel depth, screenBits.rowBytes remains the same. This is
>very nasty. What is the right way of getting screen's base address, and should
>I always switch machine to 32 bit addressing mode before writing to the
>screen?

screenBits.rowBytes stays the same for a good reason--it _is_ the same,
at least on your machine.  The standard Apple 8-bit card, for example,
will always have a rowBytes of 1024, no matter how many bytes wide the
image actually is.  If you're in 8-bit mode, 384 bytes per line are
going to waste;  if you're in 1-bit mode, 944.  (That way-cool screen
extender by that European dude, I think it's called MaxApplScreen or
something like that, makes use of the extra ram on the card, by the way.
Except I can never remember the name of the control panel, I always
think "MaxApplZone"...anyway...)

The Right(tm) way of getting a screen's base address is to decide which
screen you want from the device list, and use
(**(**theGDevHndl).gdPMap).baseAddr.  Generally, you should always swap
into 32-bit mode before writing to the screen (or anyplace not in main
RAM).  I say "generally" because if you know for a fact that the screen's
address is a 24-bit address, you don't need to--but why _not_ call
SwapMMUMode()?

>6). How come screenBits is a bit map, but the screen is color? since
>screenbits is a bitmap, the high bit of its rowBytes should be cleared. This
>means using copyBits on the screen will produce b/w images, if not nonsense.

screenBits is a holdover from 9-inch-screen days.  The Right(tm) way to
get a screen's PixMap is to walk the GDevice list, as I said above.
I don't know whether screenBits was upgraded to a PixMap, or what the
story is, because I never use it.  It's a very rare occasion that you
know for sure that the main screen is the one you want.

>7). At what times EXACTLY should strip address be used, and at what times
>EXACTLY should SwapMMUMode be used?

"Concentrate and ask again."  :-)  Seriously, Tech Note #213
("StripAddress: the Untold Story") explains stripping and MMU modes
quite well.

>Also, if I want to write to
>another screen, do I call SetGDevice? If so, what happens to my screenBits?

No, you don't have to.  Change the current GDevice and you change the
color environment--for example, I believe the Color Manager call
Color2Index will decide on an index based on the new GDevice's inverse
table.  You won't affect QuickDraw calls (hopefully), because they all
go through DeviceLoop anyway.  I have no idea whether screenBits will
reflect the current GDevice, or always the main one.

>Can the device be changed when I call WaitNextEvent? I mean, when I return
>from WaitNextEvent, should I always switch to the my own device, like I do
>with ports?

I believe the rule is--always leave the current GDevice where you found
it.  (And I believe that, if others follow the rule, you'll always find
it set to the main device.)  So, do GetGDevice/SetGDevice/.../SetGDevice.

If you need to, that is--when you're drawing direct to screen, there
isn't much reason to change the current GDevice.

>I used to calculate screen width by taking screenBits.rowBytes and multiplying
>it by 8.

This is not a good thing to do.  (Although I must say it's interesting
to try to figure out what's going on inside your computer.)  Trust
rowBytes.  If you want screen width, subtract left from right.

>Also it doesn't make sense that in
>1 bit mode screenbits.rowBytes is 1024 (!!), while in 8 bit mode it's 512
>(??).

Makes no sense to me neither--check that value with the 8-bit screen
again.  I'll bet it's still 1024.


Also, I highly recommend Forrest Tanaka's short develop article entitled
"Graphical Truffles" (sorry, I forget which issue, email me if you need
to know).  It cleared a lot of cobwebs out of my Color QuickDraw
paradigm.  Develop is downloadable from ftp.apple.com.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Was bringt mich nicht um...

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 29 Sep 92 22:21:09 GMT
Organization: MacDTS Marauders

In article <[e-mail]>,
[e-mail] (Doug McNaught) wrote:
>
>
> Hey friendly netters,
>   A friend of mine is working on a program that draws directly to the
> screen in a window, and he has some questions about StripAddress and
> maintaining as much compatibility as possible with various models. The
> program runs in 8-bit mode and requires Color QuickDraw. I'm going to
> append the message he sent me and you can reply to him, myself, or the
> net--I'll make sure he gets any useful responses.
>
> His name is Alexei Lebedev and he can be reached at
>   [e-mail]
>
> ------here we go!!!------
>
> Doug,-
>
> I'd be very grateful if you posted my problem on UseNet. In particular, I need
> to know the following:
>
> 1). IM says "strip when the system may be running 24 bit mem manager". I guess
> any system can run 24 bit memory manager. Also, no my global MaskBC variable
> is always 0x00FFFFFF, even when I'm in 32 bit mode. That means I'm always
> running 24 bit mem manager.

No; when you're in 32-bit mode, you're using the 32-bit memory manager.
The proper way to check your memory mode is to use Gestalt with the
gestaltAddressingModeAttr selector ('addr').  If bit 0 is set
(the gestalt32BitAddressing flag), then you're in 32-bit mode.  You
probably don't need to know this; see below.

> 2). How do you tell the hardware to operate in 32 bits? Should I use stripped
> addresses right away, or can I keep a variable that's a stripped address? In
> particular, when I lock my Image data structure, I do the following:
>
> HLock(destImage->baseH);
> CheckOS(MemError(), "LOCK");    /* last parameter is a routine name */
> destImage->baseAddr = StripAddress(*destImage->baseH);
>
> Is this the right way to do this?

This is OK; you can cache a stripped address safely, however, because
the "stripping" doesn't ever change; if you're in 24-bit mode, it
will always mask off the top byte; if you're in 32-bit mode, it
will always leave the address unchanged.  Stripping an address
so you can use it after switching to 32-bit mode is always an OK
thing to do; it will do the right thing, regardless of the memory
manager mode you are in previously.

> 3). When I start writing to the screen, I switch to 32 bit addressing with
> SwapMMUMode. Does this have any effect on a computer like LC?

On the LC, this has neither good nor bad effect, because the hardware is
24-bit; stripping it has no effect, but there's no reason to take it
out, either.

> 4). I use screenbits.baseAddr to get screen memory's base address. Is this
> address 32 bit clean no matter what? (I guess it should be, since it doesn't
> point to a memory manager block.) Is this a base address of the main screen?
>
> 5). When I switch pixel depth, screenBits.rowBytes remains the same. This is
> very nasty. What is the right way of getting screen's base address, and should
> I always switch machine to 32 bit addressing mode before writing to the
> screen?
>
> 6). How come screenBits is a bit map, but the screen is color? since
> screenbits is a bitmap, the high bit of its rowBytes should be cleared. This
> means using copyBits on the screen will produce b/w images, if not nonsense.

If you're attempting to draw on a color machine, you should look
through the GDevices to determine the size, depth and location of screens.
See the "Graphic Devices" chapters in Inside Mac V and VI.

> 7). At what times EXACTLY should strip address be used, and at what times
> EXACTLY should SwapMMUMode be used?

You should use SwapMMUMode any time you access the frame buffer for a
video device.  You should use StripAddress() to clean any other addresses
you wish to use while switched into 32-bit mode.  For example, if I wanted
to copy an image from a handle to the screen, I would first call
StripAddress on a pointer to the image data; this produces a clean
pointer I can use while in 32-bit mode.  I then call SwapMMUMode(); I'm
now in 32-bit mode, so I can access the screen's memory safely.  I can
then copy the data from the stripped address to the screen.  I then
call SwapMMUMode() to switch back to the mode I was in before.

> These are just some of the questions that bug me. Also, if I want to write to
> another screen, do I call SetGDevice? If so, what happens to my screenBits?
> Can the device be changed when I call WaitNextEvent? I mean, when I return
> from WaitNextEvent, should I always switch to the my own device, like I do
> with ports?

If you want to draw on another screen, find its GDevice and use the
depth and base address from that structure.  You do not need to change
the devicew, because that's a QuickDraw call, and you're not using
QuickDraw.  (Not that you would use it to draw on the screen if you
were using QuickDraw- it is intended solely for switching to offscreen
GDevices).

> I used to calculate screen width by taking screenBits.rowBytes and multiplying
> it by 8. However, when I start up in 4 bits and then switch to 8 bits (by
> using SetDepth), the cube becomes twice as large, instead of being twice as
> small. This doesn't make much sense to me. Also it doesn't make sense that in
> 1 bit mode screenbits.rowBytes is 1024 (!!), while in 8 bit mode it's 512
> (??).

Once again, use GDevices (and their associated PixMaps) to get rowBytes
and everything else.

> Hope some of them get answered.
> Have fun.
> -Alexei
>
> --
> Doug McNaught              |"Sadder still to watch it die/ Then never to have
> [e-mail]      | known it/ For you, the blind who once could see/
> [e-mail]     | The bell tolls for thee..." --Neil Peart
>   Nobody approves my opinions! Not even me, sometimes. Read at your own risk.

Tim Dierks
MacDTS, but I speak for my knees.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 30 Sep 92 02:00:03 GMT
Organization: MacDTS Marauders

In article <[e-mail]>,
[e-mail] (Jamie R. McCarthy) wrote:
> [e-mail] (Doug McNaught) writes:
> >
> >  A friend of mine is working on a program that draws directly to the
> >screen in a window, and he has some questions about StripAddress...
> >
> >His name is Alexei Lebedev and he can be reached at
> >  [e-mail]
[...]
> >4). I use screenbits.baseAddr to get screen memory's base address. Is this
> >address 32 bit clean no matter what? (I guess it should be, since it doesn't
> >point to a memory manager block.) Is this a base address of the main screen?
>
> Is it 32-bit clean?  Probably, but why take a chance?  StripAddress is a
> very quick call.  Is it the baseAddr of the main screen?  Yes.

I meant to mention this in my previous post, but I forgot.  You should
_not_ strip the address of the main screen.  It will always, and
must always be a true 32-bit address.  Here's why:

In the 24-bit memory map, there is 1 Megabyte of space allocated to
each NuBus card at the locations xxs00000 - xxsFFFFF.  In the original
slot manager, with original color QuickDraw, this was big enough to
hold all screens.  (I can't remember ever seeing a screen with more
than 1024 x 1024 pixels before 32-bit QD).  However, if you go to 32-
bit deep, even a standard 640 x 480 screen will be too big; its RAM
won't fit into the 1 Mb space (640 x 480 x 4 bytes/pixel) = 1228800
bytes = 1.2 Mb.  That means that all deep screens must be located
in an area of the address map which is only accessible in 32-bit
mode.  For convenience, cards from some manufacturers are always
located in the 32-bit address space so they don't have to support
having RAM at two different addresses.

Given all that, let's assume that you've got a 32-bit screen whose
base address is CC010000 (this is the base address of my 8o24 GC
card, in slot C).  Let's also say you've booted up into 24 bit mode.
If you switch into 32-bit mode and use this address, you'll be
just hunky-dory.  If you attempt to use StripAddress() however,
bad things will happen: the top byte of CC010000 will be masked
off, making it into 00010000, which is most definitely not your
screen buffer.  This means that the base address of any screen
GDevice's pixel map must be "pre-stripped" so it can be used as
a raw 32-bit address, because you can't strip it (or any other
pointer that might point into a NuBus card outside of the
minor slot space).

Tim Dierks
MacDTS, but I speak for the spleen.

---------------------------

End of C.S.M.P. Digest
**********************